home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
kermit.columbia.edu
/
kermit.columbia.edu.tar
/
kermit.columbia.edu
/
newsgroups
/
misc.20000824-20010305
/
000301_news@columbia.edu _Fri Feb 16 09:45:38 2001.msg
< prev
next >
Wrap
Internet Message Format
|
2001-03-05
|
7KB
Return-Path: <news@columbia.edu>
Received: from watsun.cc.columbia.edu (watsun.cc.columbia.edu [128.59.39.2])
by uhaligani.cc.columbia.edu (8.9.3/8.9.3) with ESMTP id JAA19431
for <kermit.misc@cpunix.cc.columbia.edu>; Fri, 16 Feb 2001 09:45:37 -0500 (EST)
Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.59.30])
by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id JAA07549
for <kermit.misc@watsun.cc.columbia.edu>; Fri, 16 Feb 2001 09:45:36 -0500 (EST)
Received: (from news@localhost)
by newsmaster.cc.columbia.edu (8.9.3/8.9.3) id JAA03007
for kermit.misc@watsun.cc.columbia.edu; Fri, 16 Feb 2001 09:40:42 -0500 (EST)
X-Authentication-Warning: newsmaster.cc.columbia.edu: news set sender to <news> using -f
From: fdc@columbia.edu (Frank da Cruz)
Subject: Re: interfacing to FANUC CNC controller
Date: 16 Feb 2001 14:40:42 GMT
Organization: Columbia University
Message-ID: <96je5a$2ts$1@newsmaster.cc.columbia.edu>
To: kermit.misc@columbia.edu
In article <oFaj6.275447$w35.45475640@news1.rdc1.nj.home.com>,
dls2 <dlshearer@home.com> wrote:
: I'm having some strange communications problems,
: in having Kermit communicate with a FANUC CNC
: controller. I should be able to upload and download,
: fine, with no problems, but that is just not happening.
:
: All of the hardware being interfaced is known to be
: good, so this is very unlikely to be causing problems.
:
: The connection between the FANUC CNC controller
: and the computer running K95 is a direct connection,
: being made through serial cabling, using an unknown
: pinout. The cable being used is known to be good,
: despite its unknown pinout, due to the two facts that:
:
: 1.) The serial cable does work, as intended, when
: used to connect the FANUC CNC controller to a
: different computer, making use of ProComm Plus,
: instead of Kermit. (NB: serial ports working, here.)
:
When trying to isolate faults, it is usually best to change
one thing at a time, not multiple things.
: 2.) Hardware flow control is not being utilized,
: in deference to software flow control, if any.
:
: The serial port on the computer running K95 is known
: to be good, for similar reasons, having been used, in
: other capacities, elsewhere.
:
Yes, but has it been used by K95? As you know, any serial
port above COM2 on a PC is problematic due to interrupt
conflicts. In late-model PCs, COM3 and above, if present,
might not be real serial ports. In that case, it might
be necessary to open them under their Windows names, not
their PC device names.
: As far as the settings used for communications,
: the port (COM5), port speed (9600 baud), parity
: (even), and stop-bits (2), have been set, as known
: to be needed.
:
: Duplex has been tried in both half
: and full, flow control has been tried in none, rts/cts,
: and xon/xoff, handshaking has been tried in none
: and xon, all to no affect, and no avail.
:
: The settings, from the ProComm Plus arrangement,
: indicate that half duplex and xon/xoff flow control are
: required. Settings other than 9600 baud, 7e2, full-
: duplex, and xon/xoff flow control, like handshaking,
: do not appear to be specified one way, or another,
: and, so, have, really, only been guessed at.
:
: Data is supposed to be transfered as readable, 7-bit,
: ASCII, text, from the FANUC CNC controller, through
: RS-232, to the computer running K95, and back, again,
: for purposes of backing up, and restoring, the data.
:
Without protocol, right?
: Downloads, using K95, have been done using session
: logs. The captured data is identical to that acquired by
: the ProComm Plus arrangement, with two important
: differences. The first difference is in the data header,
: where instead of the expected percent sign (%), there
: is a DC (Device Control) character (up/down arrow)
: placed before the percent sign (%), in the closed session
: logs.
:
K95 would not record this character if it did not come in.
But DC1 is Ctrl-Q or XON. If Kermit sees this as a data
character, this would indicate that you did not SET FLOW
XON/XOFF.
: The second difference is in the data footer, where
: instead of the expected percent sign (%), there is a DC
: (Device Control) character (paragraph symbol) placed
: after the percent sign (%), in the closed session logs.
:
DC-what? The Device Control characters are DC1, DC2,
DC3, and DC4, codes 0x11-0x14.
: A
: double carriage return (single note symbol) may, or may
: not, appear in the body of the text data downloaded by
: either ProComm Plus or K95, resultant from settings to
: the FANUC CNC controller, regarding communications.
:
: Why are DC (Device Control) characters appearing in
: the K95 session logs, and not in the ProComm Plus
: downloads? Handshaking?
:
You probably set Xon/Xoff flow control in PCplus but not
K95.
: Would the appearance of these DC (Device Control)
: characters in the K95 session logs I make account for
: why I cannot upload the same files back to the FANUC
: CNC controller, using "xmit <filename>", even after I
: strip these DC (Device Control) characters from the
: session logs?
:
How are you attempting to upload these files?
: In some upload attempts, with whatever setting changes
: were being tried, had an up/down arrow or, sometimes, a
: double exclaimation mark, DC (Device Control) character
: appear before a percent sign (from the data?) just prior to
: having the transfer time out on the K95 end of transfer.
:
First of all, let's straighten out the flow-control business.
It seems you believe that K95 has Xon/Xoff flow control in
effect when it does not. Maybe that's the whole problem.
: Should I have transmit linefeed set to on? This setting
: needed to be on in order for the FANUC CNC controller
: to recognize that data was even being sent to it, but
: since all attempts to send data timed out, and nothing
: was ever successfully transfered, I am unsure of if it is
: really necessary. (NB: to change LSK (Label SKip) to
: an Input mode, on the FANUC CNC controller.)
:
Aside from flow control, the real questions are:
. What are you supposed to be sending to the controller?
. Exactly what format is it supposed to be in?
. When are you supposed to send it? Are you supposed to
wait for a prompt, or what?
Is the connection full or half duplex? If you do this
by hand, does the controller echo what you type? What if
you type something too soon? Does the controller support
typeahead? etc etc.
- Frank